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Abstract 

Although  formal  methods  for  developing  computer  sys¬ 
tems  have  been  available  for  more  than  a  decade,  few  have 
had  significant  impact  in  practice.  A  major  barrier  to  their 
use  is  that  software  developers  find  formal  methods  diffi¬ 
cult  to  understand  and  apply.  One  exception  is  a  formal 
method  called  SCR  for  specifying  computer  system  require¬ 
ments  which,  due  to  its  easy  to  use  tabular  notation  and  its 
demonstrated  scalability,  has  already  achieved  some  suc¬ 
cess  in  industry.  Recently,  a  set  of  software  tools,  including 
a  specification  editor,  a  consistency  checker,  a  simulator,  and 
a  verifier,  has  been  developed  to  support  the  SCR  method 
[9,  11,  5].  This  paper  describes  recent  enhancements  to  the 
SCR  tools:  a  new  dependency  graph  browser  which  displays 
the  dependencies  among  the  variables  in  the  specification, 
an  improved  consistency  checker  which  produces  detailed 
feedback  about  detected  errors,  and  an  assertion  checker 
which  checks  application  properties  during  simulation.  To 
illustrate  the  tool  enhancements,  a  simple  automobile  cruise 
control  system  is  presented  and  analyzed. 

1.  Introduction 

Although  formal  methods  for  developing  computer  sys¬ 
tems  have  been  available  for  more  than  a  decade,  few  of 
these  methods  have  had  significant  impact  in  the  develop¬ 
ment  of  practical  systems.  A  major  impediment  to  the  use 
of  formal  methods  in  industrial  software  development  is  the 
widespread  view  that  the  methods  are  impractical.  Not  only 
do  developers  regard  most  formal  methods  as  difficult  to 
understand  and  apply.  In  addition,  they  have  serious  doubts 
about  the  scalability  and  cost-effectiveness  of  the  methods. 

A  promising  approach  to  overcoming  these  problems  is  to 
hide  the  logic  languages  associated  with  most  formal  meth¬ 
ods  and  to  adopt  a  notation,  such  as  a  graphical  or  tabular 
notation,  that  developers  find  easier  to  user.  Specifications 
in  the  more  “user-friendly"  notation  can  be  translated  au¬ 
tomatically  to  a  form  more  amenable  to  formal  analysis. 
Moreover,  to  scale  effectively,  a  formal  method  must  be 
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supported  by  powerful,  easy  to  use  tools.  To  the  extent  fea¬ 
sible,  the  tools  should  detect  software  errors  automatically 
and  provide  easy  to  understand  feedback  useful  in  tracing 
the  cause  of  an  error. 

By  providing  a  “user-friendly"  tabular  notation  with 
demonstrated  scalability,  a  formal  method  called  SCR  for 
specifying  the  requirements  of  computer  systems  has  al¬ 
ready  achieved  some  success  in  practice.  Since  SCR’s  in¬ 
troduction  more  than  a  decade  ago  [13,  1],  many  industrial 
organizations,  including  Lockheed,  Grumman,  and  Ontario 
Hydro,  have  used  the  SCR  method  to  specify  requirements. 
To  support  the  SCR  method,  we  have  recently  developed  a 
set  of  integrated  software  tools  [9,  11,  5]  to  specify  and  an¬ 
alyze  system  and  software  requirements.  The  tools  include 
a  specification  editor  for  creating  and  modifying  a  require¬ 
ments  specification,  a  simulator  for  symbolically  executing 
the  specification,  a  consistency  checker  which  checks  the 
specification  for  well-formedness  (e.g.,  syntax  and  type  cor¬ 
rectness,  no  missing  cases,  no  circular  definitions,  and  no 
unwanted  nondeterminism),  and  a  verifier  for  analyzing  the 
specification  for  critical  application  properties. 

To  place  SCR  specifications  in  perspective,  this  paper 
first  compares  an  SCR  requirements  specification  with  two 
other  specifications,  an  abstract  model  useful  in  verification 
and  a  specification  using  the  commercially  available  prod¬ 
uct  STATEMATE.  It  then  describes  the  current  status  of  the 
SCR  tools,  including  three  major  enhancements  added  since 
the  publication  of  [10,  9].  These  are  a  new  dependency 
graph  browser  which  displays  the  dependencies  among  the 
different  variables  in  the  specification,  an  improved  consis¬ 
tency  checker  which  produces  examples  of  missing  cases 
and  nondeterminism  when  either  a  coverage  or  disjointness 
error  is  detected,  and  an  assertion  checker  which  tests  vari¬ 
ous  application  properties  during  simulation.  We  also  show 
how  our  tools  support  DURATION,  a  language  feature  orig¬ 
inally  proposed  by  van  Schouwen  [25]  to  represent  time  in 
SCR  specifications.  To  illustrate  the  SCR  method  and  our 
tools,  a  requirements  specification  of  a  simple  automobile 
cruise  control  system  is  presented  and  analyzed.  Finally, 
we  present  some  lessons  learned  in  experimental  use  of  our 
tools  in  industrial  applications. 
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2.  SCR  Method:  An  Overview 
2.1.  SCR  Specifications 

A  recent  article  by  Shaw  [22]  presents  and  discusses  a 
number  of  different  specifications  of  an  automobile  cruise 
control  system.  Each  of  these  specifications  is  constructed  to 
satisfy  different  objectives.  For  example,  Atlee  and  Gannon 
use  a  logic  language  to  specify  the  different  “modes"  of  the 
cruise  control  system  [4].  Their  logic  language  specification 
is  then  fed  to  a  model  checker  that  analyzes  the  specification 
for  violations  of  selected  properties.  Another  specification 
of  the  cruise  control  system  by  Smith  and  Gerhart  is  rep¬ 
resented  using  the  graphical  notation  of  STATEMATE  and 
is  described  by  the  authors  as  a  “design  exercise"  [23],  We 
refer  to  the  former  specification  as  an  abstract  model  and 
the  latter  as  the  STATEMATE  specification. 

One  difference  between  the  abstract  model,  the  STATE- 
MATE  specification,  and  an  SCR  specification  of  the  cruise 
control  system  lies  in  the  notation.  The  abstract  model  is  ex¬ 
pressed  in  a  logic  language,  the  STATEMATE  specification 
in  a  graphical  notation,  and  the  SCR  specification  in  a  tab¬ 
ular  format.  Another  difference  is  the  target  audience.  The 
abstract  model  is  designed  to  be  processed  by  a  computer, 
whereas  both  the  SCR  specification  and  the  STATEMATE 
specification  are  engineering  documents,  designed  to  be  read 
by  software  developers.  The  three  specifications  also  differ 
in  a  third  respect — namely,  in  the  specific  information  each 
contains  about  the  required  system  behavior. 

The  objective  of  the  SCR  specification  is  to  describe  the 
externally  visible  behavior  of  the  Cruise  Control  System. 
To  achieve  this,  the  specification  must  describe  the  required 
relation  REQ  between  the  monitored  variables,  which  repre¬ 
sent  quantities  in  the  environment  that  the  system  monitors, 
and  the  controlled  variables,  which  represent  environmen¬ 
tal  quantities  that  the  system  controls.  In  the  cruise  control 
system,  the  position  of  the  cruise  control  lever  is  an  exam¬ 
ple  of  a  monitored  variable;  the  position  of  the  throttle  is 
an  example  of  a  controlled  variable.  The  REQ  relation  be¬ 
tween  the  monitored  and  controlled  variables  is  one  of  the 
four  relations  of  the  Parnas-Madey  Four  Variable  Model,  a 
formal  framework  for  describing  the  required  behavior  of  a 
computer  system  [20] . 

Atlee  and  Gannon's  abstract  model  is  used  in  verification 
and,  as  a  result,  omits  many  details  of  the  required  system 
behavior.  For  example,  it  does  not  describe  the  behavior 
of  the  throttle.  Because  the  properties  analyzed  in  [4]  are 
independent  of  the  throttle  behavior  and  because  a  model 
used  in  verification  should  only  include  information  needed 
to  reason  about  selected  properties,  omitting  information 
about  the  throttle  is  appropriate.  In  fact,  eliminating  irrele¬ 
vant  information  is  especially  important  for  model  checking: 
without  dramatic  reductions  in  the  size  of  the  state  space  to 
be  analyzed,  model  checking  is  infeasible. 


The  STATEMATE  specification  is  in  some  respects  more 
detailed  and  in  other  respects  less  detailed  than  the  SCR 
specification.  For  example,  it  presents  two  views  of  the 
required  behavior,  the  functional  view  and  the  behavioral 
view,  and  distinguishes  control  flows,  data  flows,  and  data 
stores.  The  SCR  requirements  specification  omits  this  detail 
(as  does  the  abstract  model)  because  such  detail  is  unneeded 
for  describing  externally  visible  behavior.  It  presents  a  sin¬ 
gle  “view"  of  the  required  behavior  and  makes  no  distinction 
between  control  flow  and  data  flow  nor  between  data  flows 
and  data  stores. 

The  SCR  environmental  variables  (the  monitored  and 
controlled  variables)  are  often  more  abstract  than  the  vari¬ 
ables  selected  when  other  methods  are  applied.  For  example, 
the  SCR  specification  of  cruise  control  uses  the  monitored 
variable  Speed  to  denote  the  speed  of  the  automobile.  In 
contrast,  the  STATEMATE  specification  uses  calculations 
based  on  rotations  of  the  automobile’s  drive  shaft  to  rep¬ 
resent  the  automobile’s  speed.  In  other  cases,  the  SCR 
environmental  variables  are  less  abstract  than  the  variables 
selected  using  other  methods.  The  SCR  specification  of 
cruise  control  is  explicit  about  the  relationship  between  the 
value  of  the  monitored  variable  Lever  and  the  position  in 
which  the  driver  holds  the  cruise  control  lever.  In  contrast, 
the  STATEMATE  specification  abstracts  from  much  that  is 
directly  observable  by  the  driver. 

In  contrast  to  the  abstract  model,  the  SCR  requirements 
specification  is  a  repository  for  all  of  the  information  that 
developers  will  need  to  construct  the  software  for  the  cruise 
control  system.  Hence,  it  is  necessarily  more  detailed  and 
less  abstract  than  a  model  useful  in  verification.  At  the  same 
time,  an  SCR  specification  contains  less  information  than, 
say,  a  software  design  document,  since  its  goal  is  to  describe 
the  blackbox  behavior  of  the  system  only. 

The  SCR  requirements  method  provides  detailed  guid¬ 
ance  on  exactly  what  information  belongs  in  a  requirements 
document,  a  conceptual  model  of  the  system  to  be  devel¬ 
oped,  and  special  language  constructs  to  represent  the  sys¬ 
tem  requirements.  This  detailed  guidance,  system  model, 
and  language  constructs  specialized  for  requirements  spec¬ 
ification  are  lacking  in  an  approach  based  on  STATEMATE 
because  STATEMATE,  a  general-purpose  method  that  can 
be  applied  throughout  software  development,  is  not  cus¬ 
tomized  for  requirements  specification. 

Although  the  requirements  specification  for  the  Cruise 
Control  System  presented  in  this  paper  is  close  to  a  “real" 
requirements  specification  useful  to  software  developers, 
three  classes  of  information  must  be  added  for  the  specifi¬ 
cation  to  be  complete:  a  description  of  the  I/O  devices  the 
system  uses  to  measure  and  compute  the  monitored  and  con¬ 
trolled  quantities,  the  required  timing  and  accuracy,  and  the 
constraints  imposed  on  the  system  by  physical  laws  and  the 
environment  (the  relation  NAT  in  the  Four  Variable  Model). 
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2.2.  SCR  Requirements  Model 

To  provide  a  precise  and  detailed  semantics  for  the  SCR 
method,  we  have  developed  the  SCR  requirements  model, 
which  represents  a  system  as  a  finite  state  automaton  and 
describes  the  monitored  and  controlled  variables  and  other 
constructs  that  make  up  an  SCR  specification  in  terms  of 
that  automaton  [12,  11],  To  concisely  describe  the  required 
relation  between  the  monitored  and  controlled  variables, 
our  model  uses  four  constructs — modes,  terms,  conditions, 
and  events.  A  mode  class  is  a  partitioning  of  the  system 
states.  Each  equivalence  class  in  the  partition  is  called  a 
system  mode  (or  simply  mode).  A  term  is  any  function  of 
monitored  variables,  modes,  or  other  terms.  A  condition 
is  a  predicate  defined  on  a  system  state.  An  event  occurs 
when  the  value  of  any  system  variable  changes  (a  system 
variable  is  a  monitored  or  controlled  variable,  a  mode  class, 
or  a  term).  The  notation  “@T(c)  WHEN  d”  denotes  a 
conditioned  event ,  which  is  defined  by 

@T(c)  WHEN  d  =  if  A  f'  A  d, 

where  the  unprimed  condition  c  is  evaluated  in  the  “current” 
state,  and  the  primed  condition  c'  is  evaluated  in  the  “new” 
state.  The  environment  may  change  a  monitored  quantity, 
causing  an  input  event.  In  response,  the  system  updates 
terms  and  mode  classes  and  changes  controlled  quantities. 

2.3.  Cruise  Control  System 

To  illustrate  the  SCR  constructs,  this  paper  contains  a 
specification  of  a  real  automobile  cruise  control  system  orig¬ 
inally  specified  by  Kirby  [16],  To  make  the  specification 
more  understandable,  our  specification  describes  only  a  sub¬ 
set  of  the  behavior  in  the  original.  A  special  feature  of  the 
Cruise  Control  System  is  that  time  is  an  important  monitored 
quantity.  For  example,  to  cause  the  throttle  to  accelerate  the 
automobile,  the  driver  must  hold  the  cruise  control  lever  in 
the  const  positon  for  more  than  1/2  second.  Below,  we 
show  how  the  DURATION  construct  can  be  used  to  repre¬ 
sent  this  and  other  timing  behavior  in  the  specification  of 
the  Cruise  Control  System. 

The  Cruise  Control  System  monitors  several  quantities  in 
the  automobile’s  environment,  such  as  the  ignition  switch, 
the  position  of  the  cruise  control  lever,  the  automobile’s 
speed,  and  a  service  reset  switch,  and  uses  this  informa¬ 
tion  to  control  a  throttle  and  to  determine  when  a  service 
light  illuminating  the  message,  “Major  Service  Required" 
is  off,  on,  or  flashing  (i.e.,  intermittent).  For  example,  if 
the  ignition  is  on,  the  engine  running,  and  the  brake  off, 
the  driver  can  invoke  cruise  control  by  moving  the  cruise 
control  lever  to  the  const  position.  Once  cruise  control 
has  been  invoked,  the  system  uses  the  automobile’s  actual 
speed  to  determine  whether  to  set  the  throttle  to  accelerate  or 


Figure  1.  Cruise  Control  Specification. 


decelerate  the  automobile,  or  to  maintain  the  current  speed. 
The  driver  overrides  cruise  control  by  engaging  the  brake, 
resumes  cruise  control  by  moving  the  lever  to  resume, 
and  exits  cruise  control  by  moving  the  lever  to  off.  To 
determine  when  to  illuminate  the  service  light,  the  system 
computes  the  number  of  miles  traveled  since  the  last  main¬ 
tenance  and  illuminates  the  light  intermittently  when  one 
threshold  is  reached  and  continuously  when  a  higher  thresh¬ 
old  is  reached. 

Figure  1  shows  how  SCR  constructs  can  be  used  to  spec¬ 
ify  the  requirements  of  the  Cruise  Control  System.  The  mon¬ 
itored  variables,  IgnOn,  EngRunning,  ActualMiles, 
ActualSpeed,  Brake,  Lever,  and  SvcReset,  repre¬ 
sent  the  state  of  the  automobile’s  ignition  and  engine  (each 
is  off  or  on),  the  readings  of  the  odometer  and  speedome¬ 
ter,  and  the  positions  of  the  brake,  cruise  control  lever,  and 
service  reset  switch.  Although  it  is  not  shown  in  Figure  1, 
the  distinguished  monitored  variable  Time  is  also  required 
in  this  specification.  The  controlled  variables.  Throttle 
and  SvcLight,  represent  the  state  of  the  throttle  and  the 
service  light. 

The  specification  contains  one  mode  class  and  three 
terms.  The  mode  class  CruiseControl  contains  four 
modes.  Off,  Inactive,  Cruise,  and  Override.  At 
any  given  time,  the  system  must  be  in  one  of  these  modes. 
Turning  the  ignition  on  causes  the  system  to  leave  Off  mode 
and  enter  Inactive  mode,  while  turning  the  cruise  control 
level  to  const  when  the  brake  is  off  and  the  engine  run¬ 
ning  causes  the  system  to  enter  Cruise  mode.  To  override 
cruise  control  (i.e.,  enter  Override),  the  driver  turns  the 
lever  to  off  or  applies  the  brake.  The  term  DesiredSpd 
is  set  to  the  automobile’s  actual  speed  under  certain  condi¬ 
tions,  e.g.,  if  the  driver  turns  the  lever  to  const  when  the 
ignition  is  on,  the  engine  running,  and  the  brake  off.  The 
term  SvcMiles  contains  the  number  of  miles  driven  since 
the  last  maintenance;  the  term  MilesSvcReset  is  used 
to  compute  SvcMiles. 

The  specification  also  includes  several  conditions  and 
events.  An  example  of  a  condition  in  the  specification  is 
“DesiredSpd  >  ActualSpeed".  Two  examples  of 
input  events  are  “@T(Lever=of f)"  (the  driver  moves 
Lever  from  a  position,  such  as  release,  to  off)  and 
“@F(IgnOn)"  (the  driver  turns  the  ignition  off),  where 
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Table  1.  Mode  Table  for  CruiseControi. 


Table  2.  Condition  Table  for  Throttle. 

“@T(A)"  denotes  the  event  of  A  becoming  true,  “@F(A)" 
denotes  the  event  of  A  becoming  false.  An  example  of  a  con¬ 
ditioned  event  is  “@T(Lever=resume)  WHEN  IgnOn 
A  EngRunning  A  -iBrake"  (the  driver  moves  Lever  to 
resume  when  the  ignition  is  on,  the  engine  running,  and 
the  brake  off). 

2.4.  SCR  Tables 

Among  the  tables  in  SCR  specifications  are  condition, 
event,  and  mode  transition  tables.  Each  table  defines  a  math¬ 
ematical  function.  A  condition  table  describes  a  controlled 
variable  or  term  as  a  function  of  a  mode  and  a  condition ; 
an  event  table  describes  a  controlled  variable  or  term  as  a 
function  of  a  mode  and  an  event.  A  mode  transition  table 
describes  a  mode  as  a  function  of  a  mode  and  an  event. 

Tables  1-4,  each  constructed  with  our  toolset,  are  part 
of  the  system  requirements  specification  for  the  Cruise 
Control  System.  Table  1  is  a  mode  transition  table  de¬ 
scribing  the  mode  class  CruiseControi  as  a  function 
of  the  current  mode  and  the  monitored  variables  Lever, 


Table  3.  Event  Table  for  DesiredSpd. 

IgnOn,  EngRunning,  and  Brake.  The  table  defines  all 
events  that  change  the  value  of  CruiseControi.  For 
example,  the  third  row  states,  “If  CruiseControi  is 
Inactive,  IgnOn  and  EngRunning  are  true.  Brake 
is  false  (i.e.,  off),  and  the  driver  moves  Lever  to  const, 
then  CruiseControi  enters  the  mode  Cruise."  Events 
that  do  not  change  the  value  of  the  mode  class  are  omitted 
from  the  table. 

Table  2  is  a  condition  table  describing  the  controlled 
variable  Throttle  as  a  function  of  the  current  mode  and 
the  variables  ActualSpeed,  DesiredSpd,  and  Lever. 
It  uses  a  new  language  feature  supported  by  our  tool  called 
DURATION.  This  feature  allows  the  specifier  to  define  a 
predicate  on  the  length  of  time  the  system  has  been  in  a  given 
state.  To  illustrate  how  DURATION  is  used,  we  consider 
the  condition,  “DURATIONfLever  =  const)  >  500"  in  the 
first  row  of  Table  2.  This  condition  is  true  if  the  cruise 
control  lever  has  been  in  const  for  more  than  500  ms. 
Thus,  if  the  lever  enters  the  const  position  at  time  t  and 
remains  there  for  600  ms,  at  time  t  +  400,  the  condition 
“DURATIONfLever  =  const)  >  500"  is  false',  at  time  /  +550, 
the  condition  is  true. 

Table  3  is  an  event  table  describing  the  term 
DesiredSpd  as  a  function  of  the  current  mode  and  the 
variables  IgnOn,  EngRunning,  Brake,  and  Lever. 
Like  mode  transition  tables,  event  tables  make  explicit  only 
those  events  that  cause  the  variable  defined  by  the  table  to 
change.  Table  4  is  also  an  event  table.  It  describes  the 
controlled  variable  SvcLight  as  a  function  of  the  current 
mode  and  the  variables  SvcReset  and  SvcMiles. 

To  illustrate  how  SCR  tables  can  be  transformed  into 
functions,  we  present  below  the  function  that  can  be  derived 
from  Table  1  using  our  model  [11].  This  function  describes 
the  required  behavior  of  the  mode  classCruiseControl. 
(To  save  space,  we  abbreviate  CruiseControi  as  CC  and 
EngRunning  as  EngR.) 
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Table  4.  Event  Table  for  SvcLight. 


cc'  = 


'  Off 

Inactive 

Cruise 

Override 

CC 


if  [CC=Inactive  A  @F(IgnOn)]V 
[CC=Cruise  A  @F(IgnOn)]V 
[CC=Override  A  @F (IgnOn)] 
if  [CC=Of  f  A  @T  ( IgnOn)  ]  V 
[CC=Cruise  A  @F(EngR)]V 
[CC=Override  A  @F (EngR)  ] 
if  [CC=Inactive  A  @T (Lever=const ) 
A  IgnOn  A  EngR  A  -iBrake]  V 
[CC=Override  A  [@T  (Lever=resume) 
V  @T (Lever=const)]  A 
IgnOn  A  EngR  A  -iBrake] 
if  CC=Cruise  A 

[@T  (Brake)  V  @T  (Lever=Of  f ) ] 
otherwise 


Figure  2.  Contents  of  the  Specification. 

3.  Current  Status  of  the  SCR  Tools 

This  section  describes  the  current  status  of  the  five  tools  in 
our  toolset:  the  specification  editor,  the  dependency  graph 
browser,  the  consistency  checker,  the  simulator,  and  the 
verifier.  The  dependency  graph  browser  and  the  verification 
capability  are  new.  The  specification  editor,  the  consis¬ 
tency  checker,  and  the  simulator  have  recently  undergone 
substantial  improvements. 


The  dependencies  set  Dr  of  a  variable  r  is  the  set  of 
variables  that  determine  the  value  of  the  variable.  Because 
variables  in  SCR  specifications  can  depend  on  variables  in 
both  the  current  state  and  the  new  state,  both  the  unprimed 
and  primed  versions  of  a  variable  can  appear  in  a  dependen¬ 
cies  set.  From  Table  1,  we  can  derive  the  dependencies  set 
Dec  for  the  CruiseControl  mode  class: 

{CC,  IgnOn,  IgnOn'  , Brake,  Brake'  ,  Lever,  Lever'  ,  EngR,  EngR'} 

The  value  CruiseControl  is  in  the  dependencies  set 
Dec  because  the  new  value  of  CruiseControl  depends 
on  its  current  value.  Each  dependencies  set  Dr  is  the  union 
of  two  sets  Dfd  and  D"ew ,  where  D°,d  (the  old  dependen¬ 
cies  set)  is  the  set  of  variables  on  which  variable  r  depends 
in  the  current  state  and  ‘ "  (the  new  dependencies  set)  is 
the  set  of  variables  on  which  r  depends  in  the  new  state. 

To  avoid  circular  definitions,  we  require  that  the  new  de¬ 
pendencies  sets  define  a  partial  order  on  the  variables  in  an 
SCR  specification  [11,  12].  The  monitored  variables  occur 
first  in  the  partial  order  because  they  only  depend  on  changes 
that  occur  in  the  environment  (i.e.,  their  dependencies  sets 
are  empty).  The  controlled  variables  occur  last  because  they 
can  depend  on  any  of  the  other  variables  in  the  specification. 
The  mode  classes  and  terms  appear  in  the  partial  order  be¬ 
tween  the  monitored  variables  and  the  controlled  variables. 


3.1.  Specification  Editor 

To  create,  modify,  or  display  a  given  requirements  spec¬ 
ification,  the  user  invokes  the  specification  editor.  As  il¬ 
lustrated  in  Figure  2,  the  editor  lists  the  dictionaries  and 
tables  which  make  up  the  specification.  The  dictionaries 
define  the  static  information  in  the  specification,  such  as  the 
names,  values,  and  types  of  the  variables;  the  user-defined 
types;  etc.  The  tables  are  organized  into  three  groups:  ta¬ 
bles  defining  terms,  tables  defining  controlled  variables,  and 
mode  transition  tables. 

Each  specification  contains  five  dictionaries:  the  con¬ 
stant,  type,  mode  class,  variable,  and  assertion  dictionaries. 
Figures  3-5  show  the  variable,  type,  and  assertion  dictio¬ 
naries  for  the  cruise  control  system.  Time,  which  appears  in 
both  the  variable  dictionary  in  Figure  3  and  the  type  dictio¬ 
nary  in  Figure  4,  is  represented  as  an  non-negative  integer 
with  initial  value  zero.  In  each  new  state,  time  either  stays 
the  same  or  increases.  In  the  Cruise  Control  specification, 
time  is  measured  in  milliseconds. 

The  assertion  dictionary,  a  recent  addition  to  the  toolset, 
lists  a  set  of  application  properties  that  the  specifier  can  test 
via  simulation,  or  verify  using  a  model  checker  or  mechan¬ 
ical  theorem  prover.  The  assertion  dictionary  shown  in 
Figure  5  shows  two  kinds  of  properties:  those  that  hold  in 
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Figure  4.  Type  Dictionary. 


every  reachable  state  and  those  that  hold  in  any  pair  of  adja¬ 
cent  reachable  states.  To  make  it  easy  for  users  to  formulate 
the  properties,  the  properties  are  expressed  in  standard  logic 
rather  than  some  special  logic,  such  as  temporal  logic.  The 
first  property  aBrakeOverride,  which  states  “Brake  =k 
Throttle=of  f,"  is  one  that  must  hold  in  every  reachable 
state.  The  assertion  ainactive  refers  to  variables  in  two 
adjacent  states.  In  the  column  labeled  “D/E?"  in  Figure  5, 
“E"  and  “D"  indicate  whether  checking  of  the  associated 
assertion  is  enabled  or  disabled. 


Figure  5.  Assertion  Dictionary. 

3.2.  Dependency  Graph  Browser 

One  criticism  of  SCR  requirements  specifications  is  that, 
while  they  give  detailed  information  about  specific  aspects 
of  the  required  system  behavior,  developing  intuition  about 
how  the  different  parts  of  the  specification  are  related  is  diffi¬ 
cult,  especially  for  large  specifications.  To  address  this  prob¬ 
lem,  we  have  developed  a  dependency  graph  browser  that 
displays  the  dependencies  among  the  variables  in  a  given 
specification.  Figure  6  contains  a  graph  showing  the  depen¬ 
dencies  among  the  variables  in  the  Cruise  Control  specifica¬ 
tion.  Our  tool  constructed  the  graph  automatically  from  the 
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requirements  specification.  The  monitored  variables  appear 
as  the  leftmost  nodes  in  the  graph,  the  controlled  variables 
appear  on  the  right,  and  the  nodes  representing  mode  classes 
and  terms  appear  in  the  middle. 

The  dependency  graph  in  Figure  6  provides  important 
information  about  the  Cruise  Control  specification.  For 
example,  it  shows  that  the  mode  class  CruiseControl 
is  defined  in  terms  of  the  monitored  variables  IgnOn, 
EngRunning,  Brake,  and  Lever  as  well  as  its  previ¬ 
ous  value.  Review  of  the  graph  also  shows  that  the  two 
controlled  variables  Throttle  and  SvcLight  both  de¬ 
pend  on  the  mode  class  CruiseControl. 

The  dependency  graph  can  reveal  the  presence  of  errors 
in  the  dependencies  relation.  Two  kinds  of  errors  are  pos¬ 
sible:  circular  dependencies  and  variables  with  incomplete 
definitions.  Circular  dependencies  can  only  occur  among 
variables  in  the  new  state.  (The  SCR  semantics  allow  a 
variable  to  depend  on  any  variable  in  the  current  state  [11].) 
A  variable  has  an  incomplete  definition  when  it  does  not 
lie  on  some  path  in  the  graph  that  includes  both  a  con¬ 
trolled  variable  and  a  monitored  variable.  Two  kinds  of 
incompleteness  can  occur:  a  variable  is  not  connected  to 
a  controlled  variable  (called  a  right  orphan )  or  a  variable 
which  is  not  a  monitored  variable  has  a  null  dependencies 
set  (called  a  left  orphan).  Figure  7  shows  a  graph  with  a 
cyclic  dependency,  and  Figure  8  shows  a  dependency  graph 
with  a  right  orphan.  In  Figure  7,  the  thick  arrow  (between 
MilesSvcReset  to  SvcLight)  indicates  a  circular  defi¬ 
nition  involving  the  controlled  variable  SvcLight  and  the 
terms  SvcMiles,  and  MilesSvcReset.  In  Figure  8,  the 
node  labeled  DesiredSpd  is  a  right  orphan  because  it  is  a 
term  on  which  no  controlled  variable  depends. 

Given  a  set  of  variables  lib',  the  set  of  monitored  vari¬ 
ables  IR  C  /i7;'  ,.thc  set  of  controlled  variables  OR  C  RF, 
and  the  dependencies  sets  Dr  for  each  r  in  RF,  we  can 
construct  the  dependency  graph  for  the  variables  in  RF. 


Figure  7.  Graph  with  a  Cycle. 

Ii  1 1 1-’  H  r—i  I-re'n1  Vir1  In  mm 


t. - : - 


I _ I 

Figure  8.  Graph  with  a  Right  Orphan. 

Assuming  that  there  are  n  levels  in  the  dependency  graph 
with  the  monitored  variables  at  level  1  and  the  controlled 
variables  at  level  n ,  then  the  sets  of  variables  at  each  level, 
B\,  B2,  •  •  • ,  Bn,  can  be  computed  recursively  as  follows: 

Step  1: 

•  Let  B  =  RF  —  IR  and  Bn  =  OR. 

For  Step  k  ,  k  —  2,  3, . .  . .  n  —  1,  compute  IF _ i,  IF _ 2,  •  • ., 

B2  as  follows: 

•  Remove  all  elements  of  \-2  from  B. 

•  If  B  =  0,  then  go  to  Step  n. 

•  Otherwise,  5„_fc+i  =  {r  £  B  |  V r'  £  B :  r  Dri}. 

Step  n : 

•  5,  =  IR, 

By  using  the  dependencies  sets  Dr  which  describe  all  depen¬ 
dencies,  the  above  algorithm  produces  the  /(; ’s  for  the  graph 
showing  all  dependencies.  By  using  the  new  dependencies 
sets  'p"'ew ,  the  above  algorithm  produces  the  5,  ’s  for  the 
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Figure  9.  Dependency  Graph  of  Complete 
Cruise  Control. 

graph  showing  the  variable  dependencies  in  the  new  state. 
A  slight  modification  of  the  above  algorithm  is  required  in 
the  presence  of  cycles. 

For  large  specifications,  the  complete  dependency  graph 
is  too  big  to  fit  on  the  user’s  display.  Fortunately,  a  user 
typically  wants  to  study  only  a  small  subset  of  the  depen¬ 
dency  graph.  To  display  a  subgraph,  the  user  first  finds  the 
portion  of  the  graph  of  interest  and  uses  the  mouse  to  select 
the  variables  of  interest.  Then,  the  user  can  display  the  sub¬ 
graph  containing  all  variables  that  each  of  the  selected  vari¬ 
ables  depends  on,  or  alternatively  all  variables  that  depend 
on  the  selected  variables.  Figure  9  shows  the  dependency 
graph  of  the  larger  Cruise  Control  System  originally  spec¬ 
ified  by  Kirby.  Figure  6  shows  the  simple  version  of  this 
system  specified  in  this  paper,  which  has  fewer  variables. 
To  display  this  subset,  the  user  selected  the  two  controlled 
variables  Throttle  and  SvcLight  and  then  extracted 
the  subgraph  containing  all  variables  on  which  these  two 
variables  depend. 

3.3.  Consistency  Checker 

Our  consistency  checker  [11]  verifies  application- 
independent  properties  derived  from  our  requirements 
model.  These  checks  determine  whether  the  specifications 
are  well-formed.  Among  the  errors  the  consistency  checker 
detects  are  syntax  and  type  errors,  instances  of  incomplete¬ 
ness  in  the  variable  definitions  and  dictionaries,  missing 
initial  values,  unreachable  modes,  and  circular  definitions 
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Figure  10.  Disjointness  Error. 

(such  as  the  one  shown  in  Figure  7).  The  tool  also  checks 
for  missing  cases  (called  Coverage  errors)  and  nondeter¬ 
minism  (called  Disjointness  errors). 

To  check  for  Disjointness  and  Coverage,  the  consistency 
checker  determines  whether  a  given  logical  expression  is  a 
tautology  [11].  For  example,  to  check  two  conditions  ci 
and  C2  in  a  row  of  a  condition  table  for  Disjointness,  the 
consistency  checker  evaluates  the  logical  expression  c i  A 
C2  =  false.  To  check  conditions  ci,  C2,  . . . ,  cn  in  a  row  of  a 
condition  table  for  Coverage,  the  tool  evaluates  the  logical 
expression  V  f2  V  ...  V  cn]  =  false.  To  determine 
whether  these  logical  expressions  are  tautologies,  our  tool 
applies  a  tableaux-based  decision  procedure  that  encodes 
the  algorithm  in  [24], 

When  our  consistency  checker  detects  Coverage  and  Dis¬ 
jointness  errors,  it  provides  detailed  feedback.  The  tool 
identifies  the  location  of  the  error  (e.g.,  the  specific  table 
entry  or  entries)  and  also  provides  an  example  of  a  system 
state  or  two  adjacent  system  states  containing  the  error.  This 
detailed  feedback  significantly  facilitates  user  correction  of 
errors. 

To  illustrate  the  tool’s  handling  of  a  disjointness  error,  we 
have  modified  Table  1  to  include  between  rows  3  and  4  a  new 
row  stating,  “If  in  Cruise  mode  the  driver  moves  Lever 
to  off  when  Brake  is  off,  then  the  system  enters  mode 
Off."  (See  Figure  10.)  To  check  the  modified  table  for  dis¬ 
jointness,  we  invoked  the  consistency  checker.  The  Results 
Box  in  Figure  11  reveals  a  disjointness  error.  Double  click¬ 
ing  on  the  line  Disjointness  ERROR...  displays  the 
modified  table  with  the  pair  of  entries  that  overlap  high¬ 
lighted.  (See  Figure  10.)  This  also  causes  a  specific  case  of 
overlap  to  appear  in  the  Messages  Box  of  the  Consistency 
Checker  (see  the  bottom  of  Figure  11).  This  message  states 
that  any  pair  of  adjacent  states  satisfying  Lever/off  A 
Lever1  =  off  A  -iBrake  A  CruiseControl  =  Cruise 
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Figure  12.  Coverage  Error. 
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Figure  13.  Feedback  for  Coverage  Error. 


Figure  11.  Feedback  for  Disjointness  Error. 

also  satisfies  both  highlighted  entries. 

To  check  the  two  entries  for  Disjointness,  the  tautol¬ 
ogy  checker  evaluated  the  expression,  [@T( Lever=of  f )  A 
-■Brake]  A  [@T(Brake)  V  @T(Lever=off )]  =  false.  The 
first  disjunct  in  this  expression,  @T(  Lever=of  f )  A  -"Brake 
A  @T( Brake)  evaluates  io  false  due  to  the  assumption  in  our 
requirements  model  that  only  one  monitored  variable  can 
change  at  each  state  transition  [11].  The  second  disjunct, 
@T(Lever=of f )  A  -"Brake  A  @T(Lever=of f ),  can  be 
simplified  to  @T(Lever=of f )  A  -"Brake.  Because  this 
expression  does  not  equal  false,  the  statement  is  not  a  tau¬ 
tology.  This  expression  provides  the  counterexample  shown 
in  the  Results  Box  in  Figure  11. 

To  illustrate  the  tool’s  handling  of  a  coverage  error,  we 
modified  the  first  row  of  Table  2  (see  Figure  12).  We  then 
applied  the  consistency  checker,  which  detected  a  coverage 
error.  Double  clicking  on  the  line  Coverage  ERROR.  .  . 
displays  the  modified  table  with  the  row  containing  the  rel¬ 
evant  entries  highlighted.  This  also  causes  an  example  of 
a  missing  case  to  appear  in  the  Messages  Box  of  the  Con¬ 
sistency  Checker  (see  the  bottom  of  Figure  13):  the  ta¬ 
ble  does  not  define  the  required  behavior  of  Throttle  for  a 
system  state  satisfying  ActualSpeed  >  DesiredSpd  A 
DurationConst  >  500. 

A  Coverage  error  occurs  when  the  tautology  checker 
processes  a  formula  that  does  not  evaluate  to  false.  To  find  a 
counterexample,  we  can  express  the  formula  in  Disjunctive 


Normal  Form  and  then  search  for  the  first  conjunct  that  does 
not  evaluate  to  false.  The  tool  presents  this  conjunct  to  the 
user  as  a  counterexample. 

To  evaluate  the  first  row  of  the  table  in  Figure  12  for 
coverage,  the  tautology  checker  evaluated  the  expression1 

[DesiredSpd  <  ActualSpd]  A  [(DesiredSpd  / 

ActualSpd)  V  (DurationConst  >  500)]  A 

[(DesiredSpd  >  ActualSpd)  V  (DurationConst  > 
500)]  A  true.  The  first  conjunct  of  the  expression  in  Dis¬ 
junctive  Normal  Form  is  [(DesiredSpd  <  ActualSpd)  A 
(DesiredSpd  /  ActualSpd)  A  (DesiredSpd  > 

ActualSpd)  A  true),  which  reduces  to  false.  The 
second  conjunct  is  [(DesiredSpd  <  ActualSpd)  A 
(DesiredSpd  f  ActualSpd)  A  (DurationConst  > 
500)  A  true],  which  simplifies  to  (DurationConst  > 
500)  A  (DesiredSpd  <  ActualSpd).  The  tool  presents 
this  simple  form  to  the  user  as  a  counterexample  (see  Fig¬ 
ure  13). 

3.4.  Assertion  Checking  during  Simulation 

The  user  can  validate  the  specification  by  executing  the 
simulator  and  analyzing  the  result  to  ensure  that  the  speci¬ 
fication  captures  the  intended  behavior.  In  the  new  version 
of  the  simulator,  the  user  can  also  define  several  properties 
believed  to  be  true  of  the  required  system  behavior  and,  us- 

1  Although  our  tool  represents  the  condition 
DURATION(Level=const)  >  500  as  _DUR_Lever_EQ_co  >  500,  in 
the  formulas  we  represent  this  expression  as  DurationConst  >  500. 
We  represent  other  conditions  containing  DURATION  similarly. 
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Figure  14.  Simulator  Display. 


ing  simulation,  execute  a  series  of  scenarios  to  determine 
whether  any  violate  the  properties. 

The  user  begins  by  invoking  the  simulator  and  then  step¬ 
ping  through  a  scenario,  a  sequence  of  input  events.  To 
compute  each  new  state  from  an  input  event  and  the  current 
state,  the  simulator  applies  the  transform  (i.e.,  next-state) 
function  of  our  requirements  model.  As  each  new  state  is 
computed,  the  Simulator  window  is  updated  to  reflect  the 
new  state.  The  simulator  also  supports  a  second  window, 
called  the  Log.  The  Log,  which  shows  the  state  history, 
displays  the  initial  state  in  full.  For  each  subsequent  state, 
it  lists  the  input  event  that  caused  the  transition  along  with 
each  dependent  variable  (mode  class,  term,  or  controlled 
variable)  whose  value  has  changed. 

The  scenario  in  Figure  15  demonstrates  the  behavior  of 
the  Throttle  as  defined  by  Table  2.  When  the  ignition 
is  turned  on,  the  engine  running,  and  the  brake  off,  moving 
the  cruise  control  lever  to  const  causes  the  throttle  to 
maintain  the  current  speed  of  60  mph  (State  6).  Once  the 
driver  releases  the  lever  and  the  actual  speed  drops  to  55 
mph,  the  throttle  accelerates  the  automobile  (State  9). 

To  display  the  rule  that  caused  a  given  dependent  vari¬ 
able  to  change  value,  the  user  double  clicks  on  the  variable 
and  its  value  in  the  Log.  The  simulator  then  displays  the 


Figure  15.  Log  with  a  Violated  Assertion. 


Figure  16.  Table  with  Rule  Highlighted. 


table  that  defines  the  variable,  highlighting  the  rule  that 
caused  the  change.  For  example,  double  clicking  on  the 
expression  “Throttle  =  maintain"  in  State  6  of  the 
Log  in  Figure  15  causes  the  simulator  to  display  the  ta¬ 
ble,  shown  in  Figure  16,  that  caused  Throttle  to  change 
from  off  to  maintain.  As  shown  in  Figure  16,  the 
simulator  has  highlighted  the  rule  that  caused  the  change: 
“If  the  mode  is  CruiseControl,  DesiredSpd  equals 
ActualSpeed,  and  DurationConst  is  no  more  than 
500  ms,  then  Throttle  is  maintain." 

The  bottom  line  of  Figure  1 5  demonstrates  the  detection 
by  the  simulator  of  a  violated  assertion.  The  user  simply 
clicks  on  the  line  in  the  Log  reporting  the  violation  to  display 
the  violated  assertion.  The  tool  then  displays  the  assertion 
dictionary  with  the  violated  assertion  highlighted  (Figure  5, 
which  omits  the  highlighting  to  improve  readability).  In  this 
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Figure  17.  Mode  Table  with  Rule  Highlighted. 

case,  the  violated  assertion,  aBrakeOverride,  states  that 
when  the  brake  is  applied,  the  throttle,  which  is  controlled 
by  the  cruise  control,  should  be  off.  Inspection  of  the  Log 
(Figure  15)  raises  the  question:  Why  didn’t  the  throttle  go 
off?  Clicking  on  Throttle  in  State  10  of  the  Log  (the  last  time 
Throttle  changed)  displays  the  table  defining  Throttle  (see 
Figure  16).  The  table  shows  that  Throttle  =  off  only 
when  the  mode  class  CruiseControl  ^  Cruise.  This 
raises  the  question:  Why  is  CruiseControl  =  Cruise 
when  the  driver  is  pressing  the  brake  (Brake  =  true  inState 
11)? 

Clicking  on  CruiseControl  in  State  6  (the  last  time 
it  changed)  displays  the  mode  transition  table  (Figure  17). 
We  see  that  the  system  is  still  in  mode  Cruise  while  the 
brake  is  pressed  because  there  is  no  transition  out  of  mode 
Cruise  when  the  driver  presses  the  brake  (denoted  by 
the  event  @T(Brake)).  The  event  in  the  sixth  row  of  the 
mode  transition  table  is  @T(Lever  =  off).  It  should  read 
@T(Lever  =  off)  OR  @T(Brake). 

Assertion  checking  during  simulation  differs  in  impor¬ 
tant  ways  from  model  checking,  a  form  of  verification  that 
checks  all  system  states  (or  all  pairs  of  adjacent  system 
states)  for  violations.  In  contrast,  assertion  checking  during 
simulation  is  a  form  of  testing  which  only  analyzes  a  small 
number  of  the  possible  states. 

Assertion  checking  during  simulation  has  an  important 
advantage:  it  is  much  less  expensive  computationally  than 
model  checking.  Although  the  complexity  of  model  check¬ 
ing  simple  properties  is  linear  with  respect  to  the  state  space, 
the  state  space  of  SCR  specifications,  even  small  ones,  is 
usually  huge.  For  example,  a  simple  analysis  of  the  vari¬ 


able  values  and  type  information  in  the  variable  and  type 
dictionaries  (see  Figures  3  and  4)  shows  that  the  simple 
cruise  control  system  has  over  1020  states.  Because  check¬ 
ing  SCR  specifications  requires  checking  both  the  current 
state  and  the  new  state,  the  number  of  states  to  be  analyzed 
exceeds  1040!  Hence,  it  makes  sense  to  check  assertions 
via  simulation  early  in  the  development  of  the  requirements 
specification  to  weed  out  errors;  model  checking  is  more 
cost-effective  when  the  requirements  specification  is  more 
mature.  Assertion  checking  also  requires  much  less  effort. 
Before  model  checking  can  proceed,  an  abstract  model  with 
fewer  states  must  be  extracted  from  the  specification.  Gen¬ 
erating  such  a  model  can  be  nontrivial. 

3.5.  Verifier 

We  recently  integrated  Spin  [14],  a  tool  that  uses  state 
exploration  to  verify  properties  of  finite  state  machine  mod¬ 
els,  into  our  toolset  [5] .  Our  state-based  requirements  model 
provides  a  formal  basis  for  using  such  a  tool  to  verify  re¬ 
quirements  specifications.  To  do  model  checking,  the  user 
enters  the  property  to  be  analyzed  into  the  assertion  dic¬ 
tionary  and  then  invokes  Spin  from  within  the  toolset  to 
check  the  specification  for  the  property.  Because  the  large 
state  space  associated  with  most  SCR  specifications  makes 
model  checking  infeasible,  the  user  must  provide  Spin  with 
an  abstract  model  of  the  SCR  specification.  Reference  [5] 
describes  how  our  tool  translates  SCR  specifications  into 
Promela,  the  language  of  Spin,  and  the  techniques  we  de¬ 
veloped  to  generate  abstract  models  from  an  SCR  specifica¬ 
tion.  To  date,  we  have  used  Spin  to  verify  two  requirements 
specifications,  one  a  small  safety  injection  system  [10]  and 
the  second  a  simple  autopilot  [6],  for  state  invariant  prop¬ 
erties.  These  properties  can  involve  any  variables  in  the 
specifications — terms  and  controlled  variables  as  well  as 
mode  classes  and  monitored  variables. 

4.  Applying  the  Tools  in  Practice 

Our  tools,  including  two  of  the  enhancements  described 
above,  have  already  proven  valuable  in  ongoing  experiments 
in  which  our  group  and  colleagues  in  industry  have  applied 
the  SCR  method  to  practical  applications.  Recently,  the  SCR 
tools  have  been  used  extensively  by  engineers  at  Rockwell 
Collins  Avionics  &  Communications  to  develop  and  to  ana¬ 
lyze  an  SCR  specification  of  a  reasonably  large  and  complex 
avionics  application.  In  developing  the  SCR  specification, 
the  engineers  detected  numerous  errors,  some  in  creating  the 
SCR  specification,  others  by  running  the  simulator,  and  still 
others  by  applying  consistency  checking  [18].  A  software 
engineer  at  NORTEL  has  also  used  our  tools  to  develop  and 
analyze  an  SCR  specification  of  a  Steamer  Boiler  Controller 
Problem  and  also  reports  that  the  tools  were  helpful  [26]. 
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Our  experience  and  the  experience  of  colleagues  at  both 
Rockwell  and  NORTEL  is  that  software  tools  are  not  only 
useful  but  essential  for  detecting  errors  in  large  specifica¬ 
tions  [18,  26].  Although  manual  inspections  detect  some 
errors,  our  tools  find  errors  that  manual  inspections  miss  no 
matter  how  careful  the  developers  are  in  preparing  the  spec¬ 
ification.  This  is  evidenced  by  the  experience  of  an  engineer 
at  Rockwell,  who  reports  that 

. . .  even  preliminary  execution  of  the  specifica¬ 
tion  and  completeness  and  consistency  checking 
has  found  several  errors  in  a  specification  that 
represented  our  best  effort  at  producing  a  correct 
specification  manually  [18]. 

In  the  case  of  large  specifications,  detecting  the  cause  of 
an  error  can  be  very  difficult  and  time-consuming  without 
counterexamples  such  as  those  described  in  Section  3.4.  To 
determine  the  cause  of  an  error,  the  developer  could  analyze 
the  events  and  conditions  highlighted  by  the  tool,  but  such 
analysis  is  tedious  and  error-prone.  Most  often,  the  tool 
can  find  a  counterexample  much  more  quickly  than  a  person 
can.  Once  the  developer  understands  the  error,  he  or  she  can 
look  for  a  solution. 

The  dependency  graph  browser  has  been  especially  use¬ 
ful  during  the  early  stages  in  the  development  of  an  SCR 
requirements  specification  of  a  safety-critical  Navy  applica¬ 
tion.  The  basis  for  this  effort  is  the  specification  produced 
by  the  Navy  contractor.  This  specification,  a  combination 
of  prose,  diagrams,  and  formal  statements  of  the  required 
system  properties,  contains  over  300  variables.  Our  un¬ 
derstanding  and  that  of  the  Navy  manager  of  the  depen¬ 
dencies  among  the  many  system  variables  has  been  aided 
enormously  by  the  dependency  graph  generated  by  our  tool. 
Without  understanding  how  the  variables  are  related,  speci¬ 
fying  the  system  behavior  in  SCR  would  be  very  hard. 

Applying  our  techniques  to  practical  systems  has  led  us 
to  improve  the  tools  in  other  ways  as  well.  For  example, 
occasionally  our  consistency  checker  cannot  determine  in 
a  short  time  whether  a  complex  expression  is  a  tautology. 
To  prevent  the  tool  from  becoming  mired  in  lengthy  and 
complex  analysis,  we  have  installed  a  new  tool  feature  which 
permits  the  user  to  set  a  maximum  time  for  analysis  of  a 
given  logical  expression.  This  allows  the  checker  to  perform 
the  easy  analyses  first.  The  more  complex  analyses  can  be 
postponed,  or  alternatively  the  user  can  study  the  expression 
that  is  causing  a  problem  to  determine  why  the  analysis 
requires  so  much  time. 

Although  assertion  checking  during  simulation  is  avail¬ 
able,  our  industrial  colleagues  have  not  yet  used  this  feature. 
Once  a  more  complete  SCR  specification  of  the  Navy  ap¬ 
plication  is  ready,  we  plan  to  use  assertion  checking  during 
simulation  to  analyze  the  specification  for  the  safety  prop¬ 
erties  presented  in  the  original  contractor  specification. 


5.  Related  Work 

The  two  techniques  most  closely  related  to  ours  are  Table- 
wise  [15]  and  the  Requirements  State  Machine  Language 
(RSML)  and  associated  tools  [17,  8].  Tablewise,  a  tech¬ 
nique  for  processing  decision  tables,  checks  a  table  for  both 
Disjointness  (called  “consistency”)  and  Coverage  (called 
“completeness”).  It  improves  on  earlier  techniques  based 
on  decision  tables  by  supporting  nonboolean  variables. 

The  primary  goal  in  the  RSML  research  is  to  develop 
techniques  for  producing  safe  systems.  RSML,  which  was 
designed  to  describe  real-time  process  control  systems,  uses 
a  combination  of  the  graphical  Statecharts  notation  [7]  and 
tables.  A  prototype  tool  has  been  developed  for  checking 
RSML  specifications  for  “completeness”  (i.e.,  every  possi¬ 
ble  input  event  and  the  system’s  response  to  the  event  must 
be  stated  explicitly)  and  “consistency”  (i.e.,  no  input  event 
can  cause  a  transition  to  two  different  system  states).  The 
tool,  which  has  been  applied  to  large  portions  of  the  re¬ 
quirements  specification  of  TCAS  II,  a  collision  avoidance 
system  for  commercial  aircraft,  detected  errors  not  caught 
by  an  extensive  manual  review.  Other  tools  are  also  being 
developed  to  analyze  RSML  specifications. 

Another  related  system  is  the  Prototype  Verification  Sys¬ 
tem  (PVS)  [  1 9] ,  a  specification  and  verification  environment 
developed  by  SRI.  PVS  consists  of  a  specification  language, 
a  type  checker,  and  an  interactive  proof  checker.  The  PVS 
specification  language  is  based  on  a  typed  higher-order  logic. 
The  PVS  pro ver  performs  a  series  of  inference  steps  that  can 
reduce  a  proof  goal  to  simpler  subgoals.  These  subgoals  can 
be  discharged  automatically  by  the  primitive  proof  steps  of 
the  prover.  The  primitive  proof  steps  incorporate  decision 
procedures  for  doing  arithmetic,  automatic  rewriting,  and 
BDD-based  boolean  simplification.  Although  some  are  at¬ 
tempting  to  use  the  language  of  PVS  to  produce  require¬ 
ments  specifications,  PVS  is  primarily  designed  to  specify 
mathematical  models  and  to  prove  theorems  about  those 
models  using  deductive  reasoning  supported  by  powerful 
decision  procedures. 

6.  Conclusions 

While  the  enhancements  described  in  this  paper  are  rel¬ 
atively  straightforward,  they  have  helped  to  make  our  tools 
significantly  more  useful  for  industrial-strength  applica¬ 
tions.  Further  enhancements  to  the  tools  are  planned: 

•  Although  the  number  of  cases  the  consistency  checker 
can  handle  has  increased  substantially  in  the  period 
since  its  introduction,  occasionally  the  checker  encoun¬ 
ters  logical  expressions  that  are  too  complex  to  analyze 
efficiently.  We  are  investigating  tools  such  as  Omega 
[21]  and  PVS  that  can  rewrite  and  simplify  these  ex¬ 
pressions  so  they  may  be  analyzed  more  efficiently. 
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•  In  another  project,  we  have  built  an  environment  called 
TAME  for  specifying  and  proving  properties  about 
real-time  systems  on  top  of  PVS  [2,  3],  We  are  cur¬ 
rently  exploring  the  integration  of  TAME  into  our  SCR 
toolset.  Integration  of  TAME  will  allow  the  user  of  our 
tools  to  verify  SCR  specifications  using  a  mechanical 
theorem  prover. 

Our  hope  is  that  our  enhanced  tools  will  be  used  to  pro¬ 
duce  high-quality  requirements  specifications.  These  spec¬ 
ifications  should  lead  to  systems  that  are  more  likely  to 
perform  as  required  and  less  likely  to  lead  to  accidents. 
The  existence  of  high-quality  requirements  specifications 
should  also  lead  to  significant  savings  in  software  develop¬ 
ment  costs. 
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